This test invokes :Git commit --allow-empty, which can start a real git commit process and may leave persistent state in the checkout (e.g., .git/index.lock) or fail due to missing git user identity. That can make the CI test suite flaky and may impact later test cases executed in the same repo. Prefer simulating the “stacked top split” deterministically (e.g., create an aboveleft split above the fugitive window and close it) without running an actual commit.

@copilot i dont want fakes/mocks i want real behaviour init a git repo of needed.

Done in d288c90. The test now initializes a real temporary git repo inside the child Neovim (via vim.fn.system), sets user.name and user.email locally, and chdirs into it — so :Git commit --allow-empty runs against a genuine git repo with proper identity, no mocks needed.

There’s an extra indentation level on the if type(integration) == "table" ... line in is_buff_integration, which makes the block harder to read and looks like an accidental formatting regression. Running StyLua (or aligning indentation manually) should fix it.

state[vim.api.nvim_get_current_tabpage()] can be nil in tabs where the VimEnter/TabNew autocmd returned early (e.g., window too small or get_vsplits() >= 2). In that case, indexing state[...].left/right here will throw. Consider ensuring the per-tab entry exists before assigning (e.g., initialize state[tab] with { left = -1, right = -1 } when missing, or add a small helper like ensure_state(tab)).

get_main_width() can return a non-number when options.main.width is a string (e.g. vim.wo.colorcolumn as suggested in README) or when a width function returns a non-number. That will break arithmetic in get_padding_width() and comparisons like vim.o.columns <= get_main_width(). Consider normalizing to a number (e.g. tonumber(...) / parse colorcolumn) and falling back to the default width (148) when the value can’t be coerced to a number.